home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
tsql
/
doc
/
tdbglossary.mail
/
000010_ahn@cbnmva.att.com _Fri Sep 10 13:29:05 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1996-01-31
|
6KB
Received: from univers.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP
id AA25866; Fri, 10 Sep 1993 13:29:06 MST
Date: Fri, 10 Sep 1993 13:29:05 MST
From: ahn@cbnmva.att.com
Message-Id: <199309102029.AA03984@univers.cs.arizona.edu>
Received: from att.UUCP by univers.cs.arizona.edu; Fri, 10 Sep 1993 13:29:05 MST
To: tdbglossary@cs.arizona.edu
Subject: Re: DEADLINE FOR ...
Greetings,
I have been out of town for some weeks, so could not send the
following comments before the deadline.
(Or is this earlier enough for the November 4 deadline ?)
If it is too late, I hope these can be considered in the next version.
I feel that some of these are rather significant (e.g. P1, P2, P6), but
may easily be incorporated in the final version.
I group them into two categories, one for changing some terms
and the other for minor adjustments.
* Proposals for changing some terms:
P1: User-defined Time (Section 3.3)
problem: User-defined time can easily be confused with
the feature for the user-defined data types,
as described in the next entry for
"Temporal Data Type".
It seems to suggest a new data type defined by users
to handle time.
This was not much of a problem before, but it will become so
when the user-defined data types become available
e.g. in SQL3.
(I think I, with Rick, am partly responsible for this misnomer)
replacing term:
User-dependent Time
The semantics of user-dependent time is dependent upon
user's interpretation, and not interpreted
by the system.
This avoids the confusion with the user-defined data types.
P2: Temporal Element (Section 3.15)
problem: This term is not intuitive, in fact counter-intuitive,
for representing a union of time intervals.
It sounds like an elementary item, e.g.
a single timestamp or a chronon.
Besides, \part{Previously Used Names} mentions
the same term again.
replacing term:
"Multi-intervals" or "Interval sets" or simply "Intervals"
I personally prefer "Multi-intervals", but anything
would be better than "temporal element".
P3: Beginning (Section 4.25)
problem: too vague when there is a better term.
replacing term:
Epoch
Epoch, I think, is the perfect term for this purpose.
P4: Time-invariant Attribute (Section 4.35)
problem: too long (-E2) when there is a better and shorter term.
replacing term:
Static
P5: Time-variant Attribute (Section 4.36)
problem: too long (-E2) when there is a better and shorter term.
replacing term:
Dynamic
P6: Predictive (Section 4.41)
problem: Term "proactive" is existing and accepted (-E7).
"proactive" is orthogonal to "retroactive" (-E1).
Term "predictive" is not precise (-E8).
Tuples inserted into a predictive bitemporal relation
instance are not just predictions about the future,
because predictions are different from facts.
Rather, such tuples represents facts that would become
effective in the future.
"Predictive" means that it may not be quite correct.
replacing term:
It is true that "proactive" is not in some dictionary, but
the term is commonly used.
Term "proactive" has been existing and accepted (+E7).
Meanings of "predictive" and "proactive" are different.
"proactive" is orthogonal to "retroactive" (+E1).
P7: Degenerate Bitemporal Relation (Section 4.42)
problem: Term "Degenerate" denotes something unusual or irregular.
Term "Degenerate relation" may mean a relation
with no attributes (columns) defined.
replacing term:
Synchronous Bitemporal Relation
If the valid and the transaction times are identical,
they are synchronous.
Term "synchronous" is existing and accepted (+E7), and
precise (+E8)
P8: new entries for Continuous Model of Time
P9: new entries for Discrete Model of Time
These are described under "Instant" and "Chronon", but deserve
separate entries considering their impacts on many aspects.
P10: Retroactive Temporal Relation (Section 4.40)
Predictive Temporal Relation (Section 4.41)
problem: Terms "retroactive" and "proactive" refers to
characteristics of an operation, rather than
a relation which is the result of such an operation.
replacing term:
Retroactive Operation
Proactive Operation
Define the concepts for the operation, not the relation.
* Minor adjustments:
A1: Section 3.2 Transaction Time
~~ database fact is stored in a database at some point in time, and
~~ after it is stored, it is current until logically deleted. The {\em
~~ transaction time\/} of a database fact is the time when the fact is
====
>> becomes
~~ current in the database and may be retrieved. Transaction times are
~~ consistent with the serialization order of the transactions.
~~ Transaction-time values cannot be after the current time.
=====
>> later than
A2: Section 3.3 Temporal Data Type
\epart{Definition}
Temporal data type may be built-in or user-defined.
(Why or how does it have to be user-defined ?)
~~ Terms belonging to a user-defined temporal data type
~~ get the same query language support as do terms
~~ belonging to built-in temporal data types such as the
~~ {\tt DATE} data type
Is this true ?
Isn't this dependent on the query language ?
A3: Section 3.24 Event
\epart{Previously Used Names}
Event relation, instant relation.
"Event" and "event or instant relation" are of
different domains, and cannot be compared.